Presence service is a widely used communication technology and service on Internet. Presence service allows the users, after logging in, to know the presence status of the other contacts that are interested in, such as online, offline, in a meeting, busy, and so on, for further communication through the instant messaging, audio/video or other communications. The users may also make use of presence authorization mechanism, such as agree, reject, block, unblock, and so on, to determine whether the watchers can see their presence status.
In the inter-domain environment of the internet or wireless network communication, the inter-domain traffic greatly increases as the service interworking between domains and the amount of users increase.
FIG. 1 shows an exemplary schematic view of a model of a presence service system. Referring to FIG. 1, in the client-server model of the basic presence service, the client plays the roles of watchers, such as B1-B4, and presentities, such as A1-A4. The watchers obtain the presence status of the presentities watched by presence server (PS) 110 and list server (LS) 120.
The presence status information may include the basic online/offline status and the advanced status, such as activity in progress, e.g., meeting, meal, busy, away, or even the user's mood state. Presence server 110 is responsible for receiving presence status published by the presentity, and distributing the presence status at the requests of the watcher. List server 120 is responsible for storing the application configuration documents, such as resource list and presence authorization rule, of client like presentity A1-A4 and watcher B1-B4. List server 120 also allows a client to read, write, and modify application configuration data stored on it.
The exemplary presence service system uses the mechanisms of publish, subscribe/notify, presence authorization rule, and resource list service (RLS) to propagate the presence status.
The presentity may send the publish requests to publish the presence status to the presence server. The watcher may use subscribe request to point the intended subscribes and the specific information on the subscribee. The specific information may include presence status or the configuration document. The presence server may use notify requests to notify the subscriber of the specific information and the subsequent content changes of that specific information.
As shown in FIG. 2, presentity A1 publishes presence status 201, such as away, to presence server 110. Watchers B1-B4 may subscribe to the intended subscribee for specific information, such as presentity A1 for the presence status of A1. Presence server 110 notifies watchers B1-B4 of the current presence status of presentity A1, such as away.
The subscribe/notify mechanism has an expire value that indicates the duration of the subscription. After presence server 110 receives the subscription message, presence server 110 must keep the subscription relation 220 between watchers B1-B4 and presentity A1. Once presentity A1 publishes new presence status, presence server 110 must use notify message to notify watchers B1-B4 during the duration of subscription. In order to keep subscriptions effective beyond the duration, the subscriber, such as watchers B1-B4, must refresh subscriptions on a periodic basis, i.e., retransmits the subscription message before the expiration.
FIG. 3 shows an exemplary schematic view of using presence authorization mechanism. Each of presentities has a presence authorization document on the list server which specifies what presence information may be given to which watchers. The content of the presence authorization document includes allow, reject and block setting and the filtering setting on presence status information by the presentity for each watcher.
As shown in FIG. 3, when presence server 110 receives the subscription (301) from the watcher, presence server 110 uses the presentity, e.g., A1, as the intended subscribee and the presence authorization document of the presentity as the specific information to issue subscription message (labeled as 302) to list server 120 through the subscription mechanism to obtain the contents of presence authorization document (labeled as 310) of the presentity for determining whether the watcher is authorized to obtain the presence status. Once the presentity changes the presence authorization settings, such as block or unblock, list server 120 must notify presence server 110 of the setting change through the notification mechanism during the duration of subscription, shown as 303. Then, presence server 110 adjusts the subscription authorization relation and uses the notification mechanism to notify the watcher, e.g., B1, shown as 304, of the presence status of presentity, e.g., A1.
FIG. 4 shows an exemplary schematic view of using resource list service mechanism. Referring to FIG. 4, to reduce the number of subscribe/notify messages, each watcher stores a resource list document 410 on the list server. The contents of resource list document 410 include all the presentities that the watcher intends to subscribe, such as B1's resource list. Through watcher B1's resource list B1_RLS (410) on list server 120, watcher B1 need not establish the subscription for each individual presentity of A1-A3, instead, watcher B1 may establish the subscription with an entire resource list and then receive notifications when the state of any of the resources in the list changes.
Watcher B1 uses the list B1_RLS as the intended subscribee and the presence status as the specific information to send the subscription to presence server 110. After receiving this subscription message for an entire resource list, presence server 110 uses the subscribe/notify mechanism to send the subscription message with the watcher as the intended subscribes and resource list document of the watcher as the specific information to list server 120 to obtain all resources within the list B1_RLS for knowing the actual individual presentity of A1-A3 to be subscribed to. Then, presence server 110 creates one back-end subscription for every resource in the resource list B1_RLS being subscribed to.
According to the presence authorization document of each of presentities A1-A3, presence server 110 aggregates the presence status of presentities A1-A3 and uses subscribe/notify mechanism to notify to watcher B1, shown as 415. When watcher B1 changes the resource list, list server 120 must use the notification mechanism to notify presence server 110 of this change during the duration of subscription, shown as 425. Then, presence server 110 adjusts the subscription relation and then notifies watcher B1.
In the deployment environment of presence service, the watcher and the presentity may belong to different domains with different presence servers and list servers. In other words, the watcher on domain A may subscribe to the presentity on domain B to form the inter-domain presence service. From the watcher point of view, the traffic analysis of presence service may be divided into three stages: initialization stage, steady stage, and termination stage.
In the initialization stage, the watcher logs in and subscribes the presence status of the resource list. Because the list includes the presentities on the foreign domain, the presence server on the watcher domain sends the subscription message to the presence server on the foreign domain. To obtain the contents and subsequent content changes on the resource list, the presence server on the foreign domain subscribes the resource list from presence server on the watcher domain to obtain the individual actual presentities to be subscribed to. Before the presence server on the foreign domain uses notification message to notify the presence status, to perform presence authorization, the presence server on the foreign domain must subscribe the presence authorization document of the subscribed presentity from the list server on the foreign domain to obtain the authorization setting and subsequent setting changes by the presentity on the watcher, and then generates corresponding presence status accordingly to notify the watcher of the presence status.
The steady stage includes the duration after the user's login and before logout. There are four non-periodical user behaviors in the steady stage that will result in inter-domain message transmission. The inter-domain message transmission caused by the user behaviors includes the watcher's subscription/notification on the presence status of presentity and the presence server's subscription/notification on the watcher's resource list. The amount of messages transmitted is proportional to the number of the watchers. When the presentity changes the presence status, the presence server must notify each subscribing watcher. The following describes the four non-periodical user behaviors.    (a) When the presentity on the foreign domain changes the presence status, the presentity uses the publish mechanism to publish its presence status change to the presence server on the foreign domain. After the presence server on the foreign domain checks all subscriptions related to the presentity, the presence server on the foreign domain uses the notification message to notify the updated presence status to the presence server on the watcher domain of the authorized watchers.    (b) The subscription refresh includes the refresh update to the three subscriptions: the watcher's subscription to the presence status of presentity, the presence server's subscription to the resource list of watcher, and the presence server's subscription to the presence authorization document of presentity.    (c) The watcher changes the resource list. Because in the initialization stage, the presence server on the foreign domain has already established the subscription for the resource list, the list server on the watcher domain will notify the changes made on the resource list by the watcher to the presence server on the foreign domain and the presence server on the foreign domain will adjust the subscription and then notify the presence status to the presence servers on the watcher domain of the related authorized watchers.    (d) The presentity changes the presence authorization. Because in the initialization stage the presence server on the foreign domain has already established the subscription for the presence authorization document, the list server on the foreign domain will notify the presence server on the foreign domain of the changes made on the presence authorization document by the presentity, and then the presence server on the foreign domain will adjust the subscription and notify the updated presence status to the presence servers on the watcher domain of the related watchers.
Before logging off, the watcher must terminate all the subscriptions in the termination stage. In addition to the watcher terminating the subscription to the presence status, the presence server must also terminate the subscription for the resource list of the watcher, and the subscription to the presence authorization document of the presentity.
As the presence service is trending intercommunication and the number of the users grows, presence federation may be very common and a very large number of messages transmitted in order to establish federation between different domains will also grow which must result in the traffic workload of the network.